The present invention relates generally to graphical user interfaces for computer systems. More particularly, the present invention relates to systems and methods for interfacing applications and operating systems which provide for flexible customization of graphical user interfaces.
The evolution of the computer industry is unparalleled in its rate of growth and complexity. Personal computers, for example, which began as little more than feeble calculators with limited memory, tape-driven input and monochrome displays are now able to tackle almost any data processing task. While this meteoric increase in power was almost sufficient to satisfy the demand of application designers and end users alike, the corresponding increase in complexity created an ease-of-use problem which the industry was somewhat slower in solving. Thus, designers were faced with a new challenge: to harness this computing power in a form usable by even those with relatively little computer training to smooth the transition of other industries into a computer-based information paradigm.
As a result, in the early to mid-1980's many new I/O philosophies, such as “user friendly”, “WYSIWYG” and “menu driven” came to the forefront of the industry. These concepts are particularly applicable to microcomputers, also known as personal computers, which are intended to appeal to a broad audience of computer users, including those who previously feared and mistrusted computers. An important aspect of computers which employ these concepts was, and continues to be, the interface which allows the user to input commands and data and receive results, which is commonly referred to as a graphical user interface (GUI).
The success of this type of interface is evident from the number of companies which have emulated the desktop environment. Even successful concepts, however, must continually be improved in order to keep pace with the rapid growth in this industry. The advent of multimedia, especially CD-ROM devices, has provided vast quantities of secondary storage which have been used to provide video capabilities, e.g., live animation and video clips, as regular components of application displays. With these and other new resources at their disposal, application designers and users alike, demand additional functionality and greater ease of use from the desktop environment.
To consider the challenges associated with continuing GUI design, consider as an example of a GUI which has evolved over time the Finder™ user interface and information management system (simply “Finder™ user interface” hereafter) which runs on the Apple Macintosh™ computer. The Finder™ user interface is based on the aforedescribed display principles using “windows” and “icons” to help manage computer information. The main or root window is called the “desktop” area, or more generally the primary display region. The desktop, or primary display region, is always open (displayed on the screen with its contents accessible or at least partially accessible), and takes up substantially the full display screen area when other windows are not open. The desktop is usually visible in the background when other windows are open.
Existing inside any particular window, including the desktop itself, are other information identifiers called “icons.” An icon is a screen identifier associated with a particular collection of computer information. Typically an icon may represent a “file” which is either a collection of data or a program or program segment. An icon also may represent the closed state of a window. Icons are graphic images displayed on the computer screen and usually correspond to the type of information stored within the file. Icons give the user access to the particular file represented by the graphic image when the icon is visible. The use of icons and windows is well known in the art.
The “file” is the information packet that the user wishes to utilize, create or modify; each particular file has an associated name identifying the file. Therefore, any given file may be located in the information management system by knowing a file name, an iconographic representation associated with the name, or a window locator name. All information (files) situated within a particular window are identified with that particular window's own identification location within the computer information management system. Therefore, any particular file information can be retrieved knowing its particular identification name and its window name. Accordingly, the resulting screen display utilizing the Finder™ user interface may be broken down into multiple windows and graphic icons.
Another important element of this (and other) conventional user interfaces is a screen cursor. The cursor allows direct user control over the user interface as described above. The Finder™ user interface is complemented with a “mouse” and a corresponding “pointer” which makes up the cursor control device. The user has control over the mouse, which is an electromechanical device that translates two-dimensional mouse movement into a two-dimensional screen position movement represented by, for example, a pointer or arrowhead. The user contacts and directs the mouse. When the mouse is moved freely on a table top, then the pointer on the screen will move in a similar and proportional manner. The mouse also contains one or more push buttons which can be used to effectuate control over the cursor pointer by selecting or deselecting specific icons or other display tools. It is said that the cursor pointer is “activated” when the mouse button is depressed and the pointer remains active until the button is released. Pointer activation may also be initiated by sequences of mouse button presses, such as a “double click” interaction which involves rapidly pressing the mouse button press twice in sequence.
Access to information in a conventional user interface system for a display management system is therefore based on windows, icons and pointer movement of the cursor. To access a file, the cursor pointer is placed on the visible icon or visible file name and the pointer is activated. A closed window may be represented by an icon or a window name. A window opens when the pointer of the cursor rests on the visible icon or visible name representing the closed state of the window and the pointer is activated. Within the open window, files may be displayed by icon or by name. An open window, of various geometries, may be rectangular and will exist within the display area of the main viewing screen on the desktop. Multiple windows may be open at one time, typically with the most foreground window corresponding to the most recently opened window and the background windows representing those opened previously. In the organization scheme described, it is appreciated that files are nested within windows and windows can be nested within other windows; the main or root window being the desktop area, or primary display region.
During a session using a window-based information system, many windows can be open at one time with many displayed icons within. Windows may overlap and partially, or entirely, hide other windows or icons. What results is that the particular information the user wants to obtain may be hidden behind several layers of windows and may be difficult to access; when an icon is hidden by another window it is temporarily not accessible. This has been referred to in the industry as the “window overlap” problem. There are several instances where window overlap problems routinely arise in the usage of conventional user interfaces. A few of the more troublesome scenarios are described below.
In order to complete a task, often the user must access a single icon within an open window that exists in the background, that is, covered or partially covered by other windows. The desired icon (“target” icon) within the window is no longer visible, and therefore not presently accessible. The overlapping windows or those that lay “on top of” the target window must be closed or moved away (“shuffled”) so that the target window and target icon are visible and thus accessible. Window shuffling is time consuming, confusing and often very tedious for the user. If multiple routine icons need to be systematically accessed in sequence then multiple window shuffling procedures may be required.
Another window overlap problem plaguing conventional user interfaces arises when the user requires two icons to complete a task and each icon is within a different window. The resulting screen display may contain several open windows from past tasks that may clutter the screen display with unwanted information. This information may obscure the desired windows and icons. In many instances the overlapping windows are not unwanted, but hold the first of the desired icons in displayable view. In order to access the second desired icon, the user may close the overlapping window that holds the first icon, then gain access to the second desired icon. Since the previously closed window holds the first desired icon it must be opened again so that the present task can be completed. Again, this process is often time consuming and confusing for the user—especially when the hidden second icon is one that is routinely required. In this case the user is engaged in constant “window shuffling” as described above.
Not surprisingly, these types of problems have received a significant amount of attention in recent years. Several user interface products have been developed which provide different solutions to the manner in which frequently used and currently active desktop objects are handled by the GUI. For example, consider the conventional GUI depicted in FIGS. 1(a) and 1(b). Therein, a “Desk Drawer” concept is implemented to provide selectively hideable access to frequently used desktop objects. FIG. 1(a) depicts the screen 75 having a desktop area 20 with the Desk Drawer closed, wherein only the handle 10 of the Desk Drawer is visible. An open window 60 containing several document icons 55-58 which are, therefore, accessible for operations by the user via cursor 50. The window 60 also includes a window title field 65 and window select region 74.
When activated, e.g., by placing cursor 50 over handle 10, the Desk Drawer “opens” to reveal its contents. In this case, icons 41, 42, 51 and 59 become visible. Now that these icons are visible, they too are available for manipulation by the user via cursor 50. Thus, the Desk Drawer concept provides a mechanism for placing frequently used icons in an out of the way, yet easily accessible location. The interested reader is directed to U.S. Pat. No. 5,657,049, entitled “Desk Drawer User Interface” for a more in depth discussion of this technique, the disclosure of which is incorporated here by reference.
Another conventional GUI, i.e., that provided with the WINDOWS 95 Operating System, tackles the problem of desktop clutter by the provision of a taskbar to organize concurrently running applications as shown in FIG. 2. Therein, the desktop window 200 includes a plurality of icons 210 as well as the taskbar 220. The icons 210 provide “shortcuts” to applications or documents which can be invoked, e.g., by “double-clicking” on the desired icon. The taskbar 220 identifies windows which are active including both those which are maximized and “minimized”, i.e., are not currently displayed on the desktop 200. Each such active application is represented on the taskbar 220 by a corresponding button, which typically has an iconic representation of the application as well as some descriptive text. As new applications are launched, representative buttons will be added to the taskbar 220, from left to right. Each existing button will be scaled in length to permit the taskbar to accommodate new buttons. To “maximize” an application residing on the taskbar 220, the user can single click on the representative button. Another feature sometimes seen in this type of conventional GUI are application bars, e.g., appbar 230. Appbar 230 typically includes a number of smaller buttons (relative to the length of buttons on the taskbar when only a few applications are resident there), which buttons can be depressed to launch a currently inactive application.
This conventional GUI, however, suffers from the drawbacks of having a rather rigidly structured layout (e.g., the user cannot select or organize the order of the buttons on the taskbar 220) and from difficulties in handling the representation of a large number of applications. As more buttons are added to the taskbar 220, each individual button becomes smaller. When, for example, between 20-30 applications have been launched and minimized, the taskbar 220 begins to add new buttons as a second layer rather than continuing the line of buttons illustrated in FIG. 2. To reach the second layer, the user must toggle the taskbar 220, i.e., not all of the buttons are visible simultaneously on the GUI. As the power of computers and number of interesting applications, documents and other objects increases, it is anticipated that users will wish to have ready access to a growing number of objects and, therefore, will find the approach depicted in FIG. 2 to be annoying and ineffective.
Another conventional GUI which attempts to solve this particular problem can be found in the NeXT™ Operating System. As illustrated in FIG. 3, and further described in U.S. Pat. No. 5,146,556, entitled “System and Method for Managing Graphic Images” (the disclosure of which is also expressly incorporated here by reference), this GUI provides an application “dock” 300 including a column of icons on the right side of the screen 310. The dock 300 is described as providing a visible mechanism for starting applications. Icons can be added and deleted to the application dock 300 by dragging them into a desired location proximate the docking area, at which time the operating system will integrate them into the dock 300.
Although somewhat more flexible in terms of allowing the user to organize its content than the taskbar/appbar of FIG. 2, the application dock 300 still suffers from its limitations in terms of the number of applications which can be docked at any one time. The icons in the dock are of a fixed size and, according to the user manual, are therefore limited to a maximum of 13 which can be included in the dock at any one time.
Thus, it can be seen that there remains a need in the art to design a GUI which provides the user with a larger degree of flexibility in terms of both the layout of the tool which manages these types of frequently used objects, as well as permitting a larger number of such objects to be managed and simultaneously displayed.